Description:

• MVEC lib previously had a future queue that would be filled with expected responses.

The Problem:

• If a single message got lost on the CAN bus, then the queue of futures would become de-synced compared to the actual responses arriving from the MVEC.
• This would cause the next response to fulfill the wrong promise, and subsequent responses would cascade into the wrong callers.

The Solution:

• Get rid of the queue in favor of a single std::optional<std::promise<T>> member variable per response type.
• When the client sends out a message that expects a reply, MVEC Lib stores a promise in the corresponding member variable and returns a std::future<T> to the caller.
• If the client tries to send out a new message of the same type while there is an unresolved promise for that message type:
  • The old promise is destroyed immediately (no timeout, no waiting)
  • The caller's old future throws broken_promise on get()
  • The new message is sent and a new promise/future pair is created
• Callers are responsible for their own timeouts via future.wait_for()
• Replaced single shared promises_mutex_ with per-type mutexes (query_mutex_, command_mutex_, population_mutex_) so parse and request methods for different types don't block each other

Additional Fixes:

• Removed static from local vars in (get_last_fuse_status, get_last_relay_status, get_last_error_status): I don't think we want those to share state across different instances. (We don't really want different instances regardless).
• Added try/catch to set_single_relay() in mvec_node.cpp to handle broken_promise from concurrent service calls (matches existing pattern in set_multi_relay())
• Updated hardware test to match new API — futures return T directly, not optional<T>
• Fixed API calls in README examples (open() to openSocket() and setReceptionCallback to setOnReceiveCallback)

Pros for this Method:

• Simpler than the queue. One slot per type, no sync issues from lost messages
• For the MVEC, there is no need to queue messages. There are only 3 types of messages that expect a response:
  • Relay State Query (doesn't change state, no need to queue)
  • Population Query (doesn't change state, no need to queue)
  • Relay Command (sets every relay at once, so each command effectively overwrites the last)
• No optional wrapping on the future. Callers get std::future<T> not std::future<std::optional<T>>
• Per-type mutexes allow a query, command, and population request to all be in-flight simultaneously

Cons for this Method:

• Callers need to handle broken_promise exceptions if they send a new request of the same type while one is pending
• Can't queue messages. It is up to the client/driver to handle sending multiple messages immediately after each other

Tests:

• Added 17 new test cases (mvec_relay_socketcan.cpp) covering: basic flow, abandon-and-resend, mismatched response, no-promise response drop, timeout, cross-type isolation, concurrent threading safety